Methods, data structures, and systems for processing media data streams

ABSTRACT

Methods, media data structures, and systems are provided for compressing, streaming, and playing media data. Data sections for frames of media data are compared, and similar data sections are stored once in a compressed media data. A meta data structure maps each similar data section in the compressed media data to its appropriate frame in the media data. A media player that is self-loading and executing is transmitted to a recipient. In one embodiment, the media player detects a network data transmission rate and configures accordingly. Next, the media player requests the meta data structure and the compressed media data and automatically begins receiving, decompressing, and playing the frames of the media data.

RELATED APPLICATION

This application is a Continuation of U.S. application Ser. No.10/369,017 filed on Feb. 19, 2003, which is incorporated herein byreference.

TECHNICAL FIELD

Embodiments of the present invention relate generally to mediastreaming, and more particularly to compressing, decompressing, andplaying media data.

BACKGROUND INFORMATION

Transmitting media data (e.g., audio, video, graphic, image, and thelike) over a network has become commonplace in today's highly connectedand wired economy. Consumers and organizations consume large quantitiesof network bandwidth and other computing resources when receiving andplaying media data. Consequently, a variety of techniques have beenattempted to manage and alleviate bandwidth and resource consumptionwhen acquiring and playing media data.

For example, when media data initially became available over networkconnections, the solution was primarily to upgrade network connectionsto T1, fiber optics, cable, Digital Subscriber Line (DSL), cable,broadband, and others. The solution was geared towards hardwareconnections having more bandwidth capabilities for handling the loadassociated with transmitting media data over a network. However, datatransmission rates can only being improved if both the sender andrecipient have a high bandwidth network connection. Thus, transmissionrates are tied to the least common denominator connection in asender-recipient relationship.

Accordingly, solutions evolved to more of a software focus in additionto higher bandwidth network connections. One such solution is referredto as media streaming. With this technique, a sender breaks the mediadata up into packets and serially transmits the individual packets overthe network to a recipient. The recipient uses additional streamingsoftware to buffer a predefined amount of media data before the mediadata is played. Once the media data begins playing, the recipientusually experiences a continuous play of the media data, since as therecipient consumes some of the media data; the buffered amount of datais being replaced with new media data that has yet to be consumed.

Higher bandwidth network connections and streaming techniques remain thepreferred method of delivering and consuming media data over a network.However, before a recipient can actually consume the media data, therecipient needs to download and install a media player on therecipient's computing device. These media players are readily availableover the Internet through a World Wide Web (WWW) browser. A few examplesinclude Microsoft's Windows Media Player, Apple's QuickTime MediaPlayer, Real Network's Real Players, and others.

Each of the commercially available media players generally requiresregistration and in some instances may require a restart of a computingdevice that downloads a media player. Some actually continually solicita recipient to upgrade to a paid version of the media player withpresumably more features and online support. The electronicsolicitations can become annoying to the recipient, as well as pop-upadvertisements that are displayed each time a recipient uses the mediaplayer. Moreover, in a business environment, it is generally notdesirable for each individual employee to download free software(freeware) on his/her computer. This is so, because the freeware is notsupported and can cause unexpected failures or other issues related todesktop management, such as maintenance, support, and upgrades.

Thus, downloading, installing, and using a media player can be timeconsuming, prohibited (in some environments), and annoying.Additionally, a large portion of Internet users still have standarddial-up connections to the internet and do not have high bandwidthequipment and/or service providers. Therefore, their network connectionsstill make media streaming a challenging and frustrating task, sincethere is large startup latencies before the media data is buffered andplayed on their computing devices. As a result, many Internet userselect not to consume media data at all.

Attempts have been made to alleviate this situation by compressing themedia data when streamed from the sender and decompressing the mediadata when consumed by the user. But, even the best conventionallyavailable media compression/decompression techniques have notappreciably remedied the problem for low bandwidth Internet users.

Therefore, there is a need for improved implementations and techniquesfor distributing media players, compressing media data, and playingmedia data. These implementations and techniques should permit lowbandwidth Internet users to consume media data in a more time efficientmanner without the need to install a proprietary media player.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow diagram of a method for processing media data, inaccordance with one embodiment of the invention.

FIG. 2 is a diagram depicting a media data structure, in accordance withone embodiment of the invention.

FIG. 3 is a diagram of a media data processing system, in accordancewith one embodiment of the invention.

SUMMARY OF THE INVENTION

In various embodiments of the present invention, techniques forprocessing media data are presented. Media frames for media data areevaluated as data sections. Similar data sections are stored in acompressed media data once. A meta data structure provides a mapping fordecompressing the compressed media data into populated media framesassociated with the original media data. A media player that isself-playing and self-executing is sent over a network to a requestingrecipient. The media player configures and acquires the meta datastructure with the compressed media data. Next, the media uses the metadata structure and the compressed media data to decompress and play themedia data for the recipient.

More specifically and in one embodiment of the present invention, amethod to process media data is described. Data sections for media dataframes of media data are evaluated. Next, similar data sections areiteratively stored as a single data section for a compressed media data.A meta data structure is generated to identify associations for each ofthe data sections in the single data section with respect to the mediadata frames to which the similar data sections are associated. Finally,a media player, the meta data structure, and the compressed media dataare streamed over a network.

DESCRIPTION OF THE EMBODIMENTS

Novel methods, data structures, and systems for processing media dataare described. In the following detailed description of the embodiments,reference is made to the accompanying drawings, which form a parthereof, and in which is shown by way of illustration, but notlimitation, specific embodiments of the invention that may be practiced.These embodiments are described in sufficient detail to enable one ofordinary skill in the art to understand and implement them, and it is tobe understood that other embodiments may be utilized and thatstructural, logical, and electrical changes may be made withoutdeparting from the spirit and scope of the present disclosure. Thefollowing detailed description is, therefore, not to be taken in alimiting sense, and the scope of the embodiments of the inventionsdisclosed herein is defined only by the appended claims.

As used herein the phrase “media data” includes data that is related tomultimedia such as, by way of example only, audio, video, graphical,image, text, and combinations of the same. Streaming refers to breakingmedia data up into configurable byte chunks, blocks, or frames andserially transmitting these pieces over a network to a one or morerecipients' computing devices. The network can be hardwired (e.g.,direct (point-to-point), indirect (e.g., Wide Area Network (WAN), suchas the Internet), and others). The network can also be wireless (e.g.,Infrared, Radio Frequency (RF), Satellite, Cellular, and others).Furthermore, the network can be a combination of hardwired and wirelessnetworks interfaced together.

A sender is a media data content provider. This can be an organization,a government, an individual, or automated applications acting on behalfof one of these entities. A recipient can be the same entities as asender, but recipients are consumers of the media data. Thus, dependingupon the transaction being performed (e.g., sending or consuming) theroles of a sender and recipient can be interchangeable, such that in onetransaction a sender is also a recipient, and a recipient is also asender.

A media player is one or more software applications that are designed toreceive, decompress, if necessary, decrypt, if necessary, and play mediadata in a recipient's computing environment. Media players can be anyexisting available media player designed and modified to automaticallyload, configure, and process media data according to the teachings ofthe present disclosure, or a custom-developed media player designed toachieve the same. In one embodiment of the present invention, the mediaplayer is a JAVA applet that can be downloaded, loaded, and executedwithin an application of a recipient's computing device (e.g., WWWbrowser, and others) without any manual intervention.

The initial media data that is processed by various embodiments of thepresent invention can be in any existing media data format. Thus, thisformat can be Moving Picture Expert Group (MPEG) format, an Audio VideoInterleaved (AVI) format, and a Quicktime Movie Format (MOV). The mediadata format can also be encrypted for purposes of validation or canitself be in a compressed format.

Data sections refer to attributes (e.g., color, dimensions, resolution,and the like) associated with portions of a media data frame. Media dataincludes a plurality of frames, when these frames are pieced together inthe correct order and continuously played by a media player within anapplication; the recipient experiences a full and continuous play of themedia data. Thus, media data includes many frames and each frame can bebroken into a plurality of data sections having data attributes.

FIG. 1 illustrates a flow diagram of a method 100 for processing mediadata, in accordance with one embodiment of the invention. Method 100 isimplemented by one of more software applications on computer accessiblemedia and is executed by a computing device (e.g., any device havingprocessing and memory capabilities). Furthermore, a sender uses method100 in the sender's computing environment in order to stream media dataand a media player to a recipient's computing device over a network. Inturn, the recipient uses the media player to consume the streamed mediadata.

At 101, media data is received or identified for processing to arecipient over a network. As previously presented, the native media dataformat can be of any format (e.g., MOV, AVI, MPEG, custom developed, andothers). The media data format can also be compressed and/or encrypted.

The media data is received or identified when a request is received froma recipient to consume the media data. In some embodiments, a specificrequest may not be needed since automated processes can automaticallytrigger or generate a request to stream the media data to the recipient.

At 102, each frame of the media data is evaluated by data section. Thesize of the data section is configurable within method 100. Theevaluated data sections are data attributes associated with a mediaframe. These attributes include by way of example only, colorattributes, dimensional attributes, resolution attributes, and others.When evaluating, comparisons are made to previous processed datasections against current processed data sections to determine datasections that are similar (e.g., having similar data attributes). Datasections can be similar if they are identical or if their dataattributes are substantially similar. What is substantially similar canbe configured within method 100 in order to produce better quality orless quality for the media data when it is subsequently played for arecipient.

At 103, the media data is iteratively processed by method 100 to locatesimilar data sections within each frame for the media data. As similardata sections are detected from previously processed data sections,these similar data sections are not stored a second time in a compressedversion of the media data that is being iteratively generated by method100. Thus, similar data sections are stored once in the compressed mediadata. When processing a first data section for the media data there isno need to do the evaluation at 102, rather the first data section isstored as is in the compressed media data. However, for all datasections processed after the first data section, there can be one ormore similar data sections detected. In these circumstances, thesesimilar data sections are not stored a second time in the compressedmedia data.

As the processing at 103 proceeds a meta data structure at 104 isgenerated for the compressed media data that is being iterativelyconstructed. The meta data structure provides a mapping for each similardata structure that identifies its serial location within the nativemedia data being compressed. Thus, a single data section can have aplurality of mappings that indicate this particular data section isassociated with a plurality of media data frames in the original mediadata. In one embodiment, the meta data structure is a character stringhaving numerical positional values that provide the appropriate mappingsfor similar data sections in the compressed media data. Of course as oneof ordinary skill in the art appreciates, any data structure providingthe appropriate mappings from the compressed media data to the originalmedia data can be used to achieve the tenets of the present disclosure.Thus, all such meta data structures are intended to fall within thebroad scope of the present invention.

Once the media data is represented by the meta data structure and thecompressed media data, the meta data structure is affixed to a firstpart of the compressed media data to represent one continuous string ofdata that will then be streamed to a recipient over a network at 105.

Concurrent or in parallel to the processing described at 101 through105, method 100 is readying a media player for delivery to the recipientover the network. Thus, at 110, a media player is identified for arecipient's computing environment. In some embodiments, this mediaplayer can be actively selected and configured by the recipient. Forexample, a recipient may request the media data via a WWW browser over anetwork that is the Internet. During this request, the recipient will beasked to select the media player desired or to provide otherconfigurable options that may not be automatically obtainable from theUniform Resource Locator (URL) request data received from the recipient,such as Random Access Memory (RAM) capabilities, browser appletcapabilities, browser type (e.g., Netscape, AOL, Internet Explorer, andothers).

At 111, the media player is configured based on automatic or manualinformation supplied by the recipient or the recipient's URL requestdata, and the media player is transmitted to the recipient over thenetwork. The media data player is written in an interpretive language,such that the software code is self-executing requiring no advancecompiling or static linking to produce an executable version of themedia player. Moreover, the media player is designed to automaticallyload and execute one fully downloaded to the recipient's computingenvironment. One example implementation, of such as software module, isa media player written as an applet, such as a JAVA applet that canself-load and self-execute within applications that support Javaapplets. Most existing WWW browser will support JAVA applets. Of courseany media player written as a self-executing and self-loadingapplication applet can be used to achieve the tenets of the presentinvention. All such implementations are intended to fall within thebroad scope of the present invention.

When the media player is loaded and automatically executed, the mediaplayer detects, at 112, a network data transmission rate supported bythe recipient's computing environment and configures accordingly at 113.The data transmission rate of the recipient's computing environmentpermits the media player to know how much buffer space and how muchcompressed media data can be streamed from the sender to the recipientto permit continuous media play. In some embodiments, this configurationcan occur when the recipient selects or configures the media player at110, and therefore, in these embodiments, no detection or configurationis needed at 112 and 113.

At 114, the media player automatically contacts the sender andidentifies the preferred chunks of data that the compressed media datashould be broken into when streaming the compressed media data to therecipient. In response to this, method 100 streams the meta datastructure with the first chunk of compressed media data. The mediaplayer then grabs the meta data structure, reads the mappings, andbuffers the first chunk of compressed media data on the recipient'scomputing device. Once the initial buffer is full, the media playerreads the meta data structure, decompresses the compressed media datafrom the buffer, and plays the uncompressed media data on therecipient's computing device.

Processing at 106, 114, and 115 continues in parallel and continuouslyuntil all the compressed media data is received at the recipient'scomputing device and decompressed and played by the media player.

Moreover, in some embodiments, the processing depicted at 101-105 can beperformed in batch and readily available to a requesting media player at114. Thus, the meta data structure and the compressed media data can benatively stored in a location readily accessible to the sender'scomputing environment. This may be particularly beneficial for contentproviders that regularly deliver media data with method 100. It may alsobe beneficial for recipients that use a content provider as a datawarehouse for their media data content.

One of ordinary skill in the art now appreciates upon reading thedescriptions of various embodiments presented above how media data canbe more efficiently processed than what has previously been available inthe industry. Now recipients need not hassle with downloading andinstalling proprietary and nuisance media players. Moreover, nowrecipients with low bandwidth network connections can experience mediaplay in a more time efficient manner, since the compression techniquesof the present invention permit the size of the original media data tobe substantially reduced over what has been available in the industry.Moreover, even recipients with higher bandwidth network connections canexperience more time efficient media play, since the initial startuplatency associated with media play is reduced with the tenets of thepresent disclosure.

FIG. 2 illustrates a diagram depicting a media data structure 200, inaccordance with one embodiment of the invention. The media datastructure 200 resides in one or more computer readable media 201. It isnot required that the media data structure 200 be contiguously stored ona single computer readable medium 201, since one of ordinary skill inthe appreciates that the media data structure 200 can be logicallyassembled and acquired from a plurality of disparate locations andcomputer readable media 201.

A sender of media data or a media data content provider uses the mediadata structure 200. The media data structure 200 includes a media player202, a meta data structure 203, and compressed media data 204. The mediadata structure 200 is a wholly contained data structure 200 that can beused to more efficiently play and stream media data 210. The datastructure 200 permits media data 210 to be automatically played andcompressed to smaller data sizes. Thus, there is no need fordownloading, installing, and restarting a computing device before themedia data 210 can be played on a computing device. Moreover, thesmaller compressed media data 204 permits reduced startup latency beforethe media data 210 is played.

The compressed media data 204 represents data sections from media framesof the media data 210 where similar data sections are stored once. Thesize of the data sections and the data attributes that define the datasections are configurable attributes of a method generating the mediadata structure 200. As an example, the data section can include colorattributes, pixel attributes, resolution attributes, audio attributes,and others.

The meta data structure 203 provides a mapping from the compressed mediadata 200 to an uncompressed version of the media data 210. In someembodiments, this mapping is a string of numeric characters thatidentify the locations and/or frames of each singly stored data sectionas it is associated in the original media data 210.

The media player 202 is a self-loading, self-executing, andself-configuring application. The media player 202, in some embodiments,requires no intervention or configuration to process. Thus the mediaplayer 202 can automatically detect the data transmission rates of aprocessing computing device, the application using the media player 202,and the like. In other embodiments, the media player 202 is configurableand permits manual adjustments for things such as application using themedia player 202, network data transmission rates, and other attributesor characteristics of a receiving computing device.

The compressed media data 204 can be broken into configurable bytesizes. The media player 202, in some embodiments, provides theconfigurable byte sizes based on the network data transmission rate of areceiving computing device. Moreover, in some embodiments, a streamingapplication 220 supplies the compressed media data 204 in the desiredbyte sizes over a network 230 to an intended recipient's computingdevice 240.

In one embodiment of data structure 200, a request is received from arecipient 240 to acquire and consume media data 210. The media player202 is identified and optionally configured for the recipient'scomputing device and transmitted over the network 230 to the recipient240. The media player 202 self-loads and starts processing withoutintervention on the recipient's computing device. The media player 202,then optionally detects the recipient's network data transmissioncapabilities to select an optimal block size to transmit the compressedmedia data 204 over the network 230 to the recipient 240. Next, themedia player 202 automatically configures and requests the first blockof compressed media data 204 over the network 230. The first blockincludes as a first part of the block the meta data structure 203. Themedia player 202 uses the meta data structure 203 to decompress andautomatically play the media data 210 on the recipient's computingdevice.

In other embodiments, the meta data structure 203 and the media playerare sent together to the recipient 240 before any portion of thecompressed media data 204 is streamed by the streaming application 220over the network 230 to the recipient 240. In still other embodiments,an initial default block size of data is used to stream the media player202, the meta data structure 203, and a first portion of the compressedmedia data 204 over the network 230 to a recipient 240. In otherembodiments, the recipient 240 may have previously used a media datastructure 200 through a previous contact with a sender of contentprovider of media data 210. In these embodiments, the media player 202may be permitted to reside within an application of the recipient andmay therefore already exist. Correspondingly, the media player 202 willnot need to be resent to the recipient 240.

One now understands how media data structure 200 functionally providessignificant advantages over what has been conventionally achieved in theindustry. More specifically, media data 210 can now be substantiallycompressed as compressed media data 204 permitting media data 210 to bemore rapidly transmitted over a network 230 and consumed by a recipient240. Furthermore, media player 202 is included within the media datastructure 200 such that a recipient need not acquire, download, install,and possibly reboot an application before the recipient can consume themedia data 210.

FIG. 3 illustrates a diagram of a media data processing system 300, inaccordance with one embodiment of the invention. The media dataprocessing system 300 is implemented as one of more softwareapplications within a computing processing environment. The media dataprocessing system 300 includes a media player 310, a meta data structure320, and a streaming application 330.

The media player 310 is implemented as one or more software applicationsand written in an interpreted software programming language, such thatthe media player 310 is capable of self-executing without the need tocompile or statically link to other modules. In one embodiment, themedia player 310 is written as a JAVA applet that is self-loaded,self-executed, and self-configured within a browser.

The meta data structure 320 is a mapping between a compressed version ofmedia data 322 and an original processed media data 324. The mappingidentifies positional information for data sections that are singularlystored in the compressed media data 322 as they are to be presented inthe media data 324 when the media data is decompressed. Similar datasections are stored once in the compressed media data 322. Similar datasections will map via the meta data structure 320 to specific framesincluded in the media data 324.

The streaming application 330 first or initially transmits the mediaplayer 310 over a network 340 to a browser application 350. The mediaplayer 310 will then self-load, self-execute, and self-configure, ifnecessary. The media player 310 then requests from the streamingapplication 330 the meta data structure 320 and that the streamingapplication 330 begin transmitting the compressed media data 322 at aconfigured data block size. The media player 310 executes within thebrowser 350 and receives the meta data structure 320 and the compressedmedia data 320. The media player 310 is operable to read and process themeta data structure 320 in order to decompress the compressed media data322 and play the media data 324 in an uncompressed format.

One now fully appreciates how media data 320 can be more efficientlyprocessed and played over a network, such as the Internet. Thesetechniques permit media players 310 to automatically be transmittedduring a consuming session by a recipient. The media players 310automatically load, execute, and configure and use a meta data structureto decompress a compressed media data 322 in a more efficient mannerthan what has been achieved in the industry.

It is to be understood that the above description is intended to beillustrative, and not restrictive. Many other embodiments will beapparent to those of skill in the art upon reviewing the abovedescription. The scope of embodiments of the invention should,therefore, be determined with reference to the appended claims, alongwith the full scope of equivalents to which such claims are entitled.

It is emphasized that the Abstract is provided to comply with 37 C.F.R.§1.72(b) requiring an Abstract that will allow the reader to quicklyascertain the nature and gist of the technical disclosure. It issubmitted with the understanding that it will not be used to interpretor limit the scope or meaning of the claims.

In the foregoing Description of the Embodiments, various features aregrouped together in a single embodiment for the purpose of streamliningthe disclosure. This method of disclosure is not to be interpreted asreflecting an intention that the claimed embodiments of the inventionrequire more features than are expressly recited in each claim. Rather,as the following claims reflect, inventive subject mater lies in lessthan all features of a single disclosed embodiment. Thus the followingclaims are hereby incorporated into the Description of the Embodiments,with each claim standing on its own as a separate exemplary embodiment.

1. A machine-implemented method, comprising: attaching a media playerand the metadata to a front end of media data; streaming the media datahaving the media player and the metadata to a browser; and automaticallyinitiating the media player within the browser and using the metadata,by the media player, to play the media data within the browser.
 2. Themethod of claim 1 further comprising, compressing the media data beforestreaming the media data.
 3. The method of claim 1 further comprising,removing the media player from the browser once the media data has beenreceived and played within the browser.
 4. The method of claim 1 furthercomprising, detecting, by the media player, a transmission rateassociated with a machine that executes the browser and receives themedia data.
 5. The method of claim 4 further comprising, self adjustingone or more operations of the media player in response to thetransmission rate.
 6. The method of claim 1 further comprising, definingblock sizes, by the media player, for streaming remaining portions ofmedia data to the browser once the media player initiates and executeswithin the browser.
 7. The method of claim 1, wherein automaticallyinitiating further includes installing the media player within thebrowser as a self-loading and self-installing software program withinthe browser.
 8. A machine-implemented method, comprising: receiving amedia stream having a media player attached on a front-end of the mediastream; automatically loading and executing the media player from thefront-end of the media stream; and using the media player to control aremaining portion of the media stream being delivered to a machine thatexecutes the media player.
 9. The method of claim 8 further comprising,acquiring, by the media player, metadata that defines a compressiontechnique used for the remaining portion of the media stream.
 10. Themethod of claim 9 further comprising, decompressing the remainingportion of the media stream by processing a decompression technique thatcorresponds to the compression technique identified in the metadata. 11.The method of claim 8 further comprising, dynamically playing theremaining portion of the media stream with the media player.
 12. Themethod of claim 8 further comprising, defining, by the media player, atransmission rate associated with delivering the remaining portion ofthe media stream.
 13. The method of claim 8 further comprising,detecting by the media player environment settings of the machine andusing those settings to control delivery of the remaining portion of themedia stream.
 14. The method of claim 8 further comprising, enforcing,by the media player licensing restrictions defined by metadataassociated with the remaining portion of the media stream.
 15. Amachine-implemented system, comprising: a media player; metadata; andcompressed media data, wherein the media player is to be attached to abeginning portion of the compressed media data along with the metadata,and wherein the media player is to self load and to self install withina recipient browser and is to consume the metadata for purposes ofcontrolling delivery of a remaining portion of the compressed mediadata, which is to be streamed to a machine that executes the mediaplayer.
 16. The system of claim 15, wherein the media player is toconsume the metadata to decompress the remaining portion of the mediadata and to play decompressed portions of the media data.
 17. The systemof claim 15, wherein the media player is to detect and adjust atransmission rate associated with delivering the remaining portion ofthe compressed media data to the machine.
 18. The system of claim 15,wherein the metadata is to define block sizes and compression techniquesassociated with the compressed media data for the media player.
 19. Thesystem of claim 15, wherein the media player unloads itself from themachine once the compressed media data has played on the machine. 20.The system of claim 15, wherein the media player is to report usagestatistics associated with playing the media data to a media source thatprovides the compressed media data.